There are multiple models for automating a supply chain, such as the traditional point-to-point partnership supply chain automation as well as participation in, and integration with trading exchanges. Mid-market supply-chain-related applications have propagated over the last several years. The advent of Enterprise Resource Planning (ERP), Material Requirements Planning or Manufacturing Resource Planning (MRP), Customer Relationship Management (CRM), Supply Chain Management and Supply Chain Execution (SCM/SCE) and Marketplace applications (see glossary at the end of this document for more information) have contributed greatly to this explosion. For the enterprise to function successfully, tight integration between applications is imperative, albeit a considerable, and sometimes costly challenge. E-Business and the expansion of cross enterprise networks have added another level of complexity to this dilemma. Without an established method for connecting applications, custom (and typically not reusable) development work is undertaken each time two disparate systems are linked.
One of the most significant obstacles to supply chain automation is the integration of disparate systems. By it's very nature, a supply chain is a conglomerate of disparate software systems, from many different software vendors, each providing a small fraction of the capabilities of the overall supply chain. A fully optimized supply chain would require all of these systems to seamlessly interact, such that a purchase by a consumer of a finished good would be aggregated and propagated throughout the entire supply chain, resulting in the re-manufacturing and replenishment of this finished good to the supplier. The act of tying all the disparate systems within a supply chain together results in the notion of a high level, or abstract “meta-system” which governs inter-system processing of data, from start to finish.
The integration of disparate systems involves the translation of data formats and correlation of events between those two systems. Business logic provides the mapping between the two systems. Because this business logic is external to each system, an external execution environment is required to support the processing of business logic. The fundamental barriers to integrating applications are incompatible data formats (the format in which data relevant to each system is stored and accessed) and incompatible event models (the methods by which system events are invoked and carried out). The result is an impedance mismatch that prevents disparate applications from communicating and sharing information.
Both mid-sized and large companies have much to gain from automating and integrating their supply chains. Many of the existing integration solutions, however, can be rather unwieldy; licensing them is often very costly, and their resource requirements are typically extensive. Without a comprehensive integration solution, however, integrating two systems involves tedious custom development highly specific to the connection between those two systems. When the time comes to integrate another pair of systems, the integration process practically starts from the beginning, since the work from the first integration is frequently not easily applicable to other business relationships.
There are problems in current approaches with trying to enable large numbers of disparate systems to interact because they are subject to transport level failures. Any solution must overcome this shortcoming, providing some measure of guaranteed message delivery. The nature of Internet protocols is inherently point-to-point. A solution requires expanding this notion to support true point-to-multi-point communications. Once the physical disparities between two systems have been resolved, the CIF must then solve the problem of the architectural disparity between two systems. This architectural disparity can be broken down into two components. First, the way in which data is represented within each system is typically vastly different. Enabling communication between two such systems requires converting one data format into the other. Second, the events that each system processes may be fundamentally different.
The internal system level events, which trigger the internal business logic of each system, must be correlated. It can be deduced that this data conversion and event model correlation requires some level processing external to either system.
Another problem with current systems is that they do not support the wide scale implementation of system level interoperability. There are many ways to accomplish this goal and many tools on the market support the development of such solutions. But these tools generally do not support ‘mass implementation’ of system level interoperability. This requires scaling deployment to support dozens, hundreds or even thousands of interoperating systems. Mass integration on this scale requires a new approach to systems integration. This type of integration requires a solution to be lightweight, remotely maintainable and require minimal support on the part of the transacting parties.
Wide scale integration implies some constraints. For instance, the deployment of a dozen installations is achievable by conventional means, i.e. visits by technical personnel to install configure and test each installation. When this number moves to the dozens, hundreds or even thousands of installations, this model does not scale. A viable solution must compensate for this limitation, so that it can support minimal technical ability on the part of the installation personnel, and fully remote maintenance of any and all installations. Maintenance refers to remote configuration, the addition of or changes to business logic, the addition or deletion of CIF software components and installation/updating of operational data.
Accomplishing wide scale integration of disparate systems provides little value, however if it exposes customers' proprietary data to prying eyes. As such, a satisfactory solution must accomplish these goals while ensuring the security of each participant's intellectual property. This entails coverage of the following security elements.                Authentication—Ensure that participants are who they say they are.        Authorization—Ensure that each participant has been granted access to other systems by a mutually trusted authority.        Non-repudiation—Ensure that neither party to a particular transaction can later deny involvement in the transaction.        Encryption—Ensure that access to sensitive data transmitted across the open Internet is restricted to the intended recipient.        Service level ACL—Ensure that access to the services implemented is restricted to the specified trading partners.        